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Secure Transmission of Data within a Distributed Computer System 

The present invention relates to the secure transmission of data within a 
distributed computer system, particularly although not exclusively to facilitate 
5 secure communication with client devices on a network. 

While the invention may be utilised in all types of network-aware devices, it is 
expected to find particular application in fields such as network cards, wireless 
LAN cards, voice over IP telephones, modems, routers, switches, hubs, TV set- 
10 top boxes, mobile telephones and the like. 

Traditionally, suppliers of network devices, and particularly consumer devices, 
have tended to accord a relatively low priority to the implementation of 
security by means of cryptography including encryption and digital signatures. 

15 Although cryptographic systems can in some cases be added on to pre-existing 
networks, either by means of software or by means of purpose-designed 
hardware security modules, such solutions are often expensive and complex to 
implement. Some progress has been made in consumer markets by allowing 
the protection of cryptographic keys in smart cards or in hardware boxes, but 

20 both of these approaches are of rather limited scope. A more recent trend is 
toward the increasing "hardening" of client devices, with cryptography being 
built in as a fundamental part of the messaging protocols to be used. 
Unfortunately, suitably powerful embedded processors capable of carrying out 
the full range of cryptographic functions, including key generation, are by no 

25 means cheap and can be large and power-hungry, which discourages their use 
within inexpensive consumer products. 

Many current systems rely on Public Key Infrastructure (PKI) in order to verify 
the integrity (authenticity of origin) of data transmitted across the network. 



the distributor, further encrypting the encrypted data according to the protocol 
to generate a secure message, and transmitting the message to the client, and at 
the client: confirming the integrity of the transmission by decrypting the 
message according to the protocol, and recovering the data by decrypting the 
encrypted data using the secret. 

The invention, in its various forms, allows us: 

(a) To define a form of Secure Processor and associated functions and 
protocols, which is designed to minimize its physical and computations 
resources by offloading functions to another Secure Processor that 
services it. 

(b) To define a framework of networked Secure Processors of that type that 
provides centralized storage, processing and distribution. 

(c) To define such a framework to support Policies that execute in Secure 
Processors that automate the enforcement of rules on the processing and 
distribution. 

(d) To define such a framework that allows separation of trust, including 
confidentiality and integrity, between parts of the framework. 

The invention further extends to a computer system including a plurality of 
clients, each having a security module as previously defined and a provider 
arranged to send messages as required, to the said clients. 



1.1 Secure Processor Definitions 



For the purpose of definition, a Secure Processor 100 of known generic type, as 
shown in figure 1, comprises: 

-a CPU 10; 

- Persistent Secure Data 11, which is information stored long-term, for 
example, using technologies such as ROM and/or EEPROM; 

- Transient Secure Data 12, which stores data only when the CPU is active, for 
example, using technologies such as RAM, and in particular such data cannot 
be expected to persist over power downs. 

A Secure Processor has one or more Secure Program(s) 13, which are stored in 
its Persistent Secure Data 1 1 and can execute on its CPU 10, when it can store 
and access Persistent Secure Data 11 and Transient Secure Data 12, and, 
potentially, other resources, such as a secure clock (not shown). 

An Insecure Computer can run Insecure Programs that can communicate with a 
Secure Processor. 

In contrast to an Insecure Program, the integrity of a Secure Program and the 
integrity and confidentiality of its execution on its Secure Computer is regarded 
as trustworthy. 

The Secure Computer 100 is typically a dedicated hardware module, such as an 
HSM (Hardware Security Module), a smart card, specialist embedded device, a 



ensuring the freshness or appropriateness of data by sending it only when the 
Micro Secure Processor needs it; transferring data that has the effect of 
delegating a command that would normally be done by the Micro Secure 
Processor to SP2. 

1.3 Secure Transfer Protocol 

One Secure Processor ('SPl') can communicate with another Secure Processor 
('SP2') using a 'Secure Transfer Protocol', which allows SPl to request some 
data from SP2. The connection between SPl and SP2 may involve one or 
more Insecure Computers. SPl could be a Secure Processor or a Micro Secure 
Processor. 

The Secure Transfer Protocol is designed so that the insecure parts of this 
system do not compromise the security of the exchange. 

The connections between SPl and SP2 can be permanent or intermittent. It can 
use wired or wireless networks, or a mixture of both. 

1.4 Data 

The Data transmitted by the Secure Transfer Protocol could contain: 

a) Key Data, which describes a cryptographic key ('Key') that SPl can use 
securely; 

b) Program Data, which is a program that could run securely on SPl, or be 
loaded to run on an Insecure Computer that is directly associated with SPl; 
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a) a symmetric key ( f Kei-secret ! ) or; 

b) an asymmetric key pair comprising 'Kei-private' and 'Kei-public\ 

5 

An entity can authenticate itself, or enforce integrity, to another Secure 
Processor using: 

a) Kei-secret to form a Message Authentication Code (MAC) or; 

10 

b) using Kei-private to make a digital signature. 

1.6 Seat of Trust Processes 

15 

As shown in figure 1, a 'Seat of Trust Process 1 14 can generate the Seat of Trust 
19 from one or more 'Seat of Trust Constants) 15, each of which can be: 

a) Persistent Secure Data 1 1 (e.g. inserted by the device manufacturer or at 
20 some stage during the sale, distribution or commissioning of the device); 

b) supplied to the Secure Processor from some external source 16, for example, 
a person entering a Personal Identity Number (TIN 1 ); or from a biometric 
mechanism that encodes some personal property as a Seat of Trust Constant. 

25 

1.7 Simple Enrollment 



Before SP2 can authenticate SP1, or rely on its statement of integrity, SP2 must 
receive: 
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or: 



b) sign( {Kei-public, Nonce, other data} , Kei-private ) 

where '{a, b}' denotes 'a concatenated with b' and 'sign(c, d)\ means 'sign c 
using key d' 

Then SP1 sends the Certificate to SP2. 

4. SP2 verifies the Certificate and the value of Nonce, by 
either: 

a) mac( Certificate, Kei-secret ) 
or; 

b) verify( Certificate, Kei-public ) 
where 'verify(a,b)' means Verify a using key b\ 

and checks that the value of the Nonce in the Certificate is that same as that 
created by SP2 in Step (1.). SP1 could also authenticate SP2 as well, where 
required (not shown). 

4.1) If this succeeds, proceed to Step (5.). 

4.2) If this does not succeed, the transfer terminates with an error and goes to 
Step (9.). 

5. SP1 and SP2 exchange messages that result in a shared 'Session Key', 
CKs'). 
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encrypt( {Data, other data}, Ke-encrypt ). 

This double-encryption concept allows the system to make a distinction 
between the security involved in distributing Data (e.g. a key) and in the use of 
that Data. The message being passed allows the recipient to rely on the 
confidentiality of the data that is being distributed and, entirely separately, to 
rely on the integrity of the distribution process itself. Provided that the secret 
known to the client (SP1) is kept confidential from the distributor (SP2), the 
client can be sure that the confidentiality of the Data is preserved. 
In one embodiment, for example, the Repository can serve up keys to micro- 
HSM endpoints without (except possibly fleetingly in an HSM connected to the 
repository) having any access to the key material. 

The data is here encrypted twice: 

• An inner encryption protects the data from the Repository. 

• An outer encryption allows for micro-HSM revocation. 

The Repository ensures that the inner encrypted blob is only sent to a micro- 
HSM if the micro-HSM (eg as identified by its Kei) is valid (eg it has not been 
revoked by the Regional Authority mentioned in section 4.2). The outer 
encryption makes use of temporary session keys which stops an attacker from 
successfully replaying old key transfer messages to attempt to load an 
encrypted blob onto a micro-HSM which has been revoked. 

One major advantage of such an arrangement is that the privacy of the key 
needed to read the original data can be maintained entirely outside the system. 
This key can be kept securely in one place (for example in the head office of a 
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8. SP1 obtains Ke-decrypt by unwrapping Message2 with the 
corresponding unwrapping key, 'Kw-unwrap', which SP1 obtained from some 
out of-band-process 

unwrap( decrypt (Message2, Ks ), Kw-unwrap ) 

9. SP2 computes 'Message3' 
encrypt( Encrypted Data, Ks ) 
and sends it to SP1 

10. SP 1 obtains Data, by decrypting Message3 : 

decrypt( decrypt (Message3, Ks ), Ke-decrypt ) 

where 'decrypt( a, b )' denotes 'decrypt a with key b'. 

Another variant is where a nested set of unwrapping keys is transferred in steps 
essentially similar to (7.) and (8.). This could be done recursively 

1.10 Wrapping Key 

One case of the protocol in (1.8), shown in figure 4, is where SP1 has an Entity 
Confidentiality Key (Kec): 



either 

a) a symmetric key, 'Kec-secret' 
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A Repository 50, which centralizes the storage of encrypted Data 52 within a 
data store 53 and may originate that Data or receive it from some out-of-band 
mechanism. 

The Repository comprises at least one Secure Processor 51 or an Insecure 
Computer interfaced with at least one Secure Processor. 

The Secure Program responsible for the Repository's activities is called the 
Guardian 54. This communicates with a Transferrer 55. 

In one configuration, as shown in figure 5, the Repository and Provider are 
merged into one component. Alternatively, the Repository may communicate 
with one or more Provider(s), using the Secure Transfer Protocol. 

Each Provider is responsible for serving Data on request to one or more User(s) 
56, each of which requests and may use Data. 

The Transferrer 55 communicates with the User 56 using the Secure Transfer 
Protocol. 

Both the Provider and the User contain a Micro Secure Processor or a Secure 
Processor, typically interfaced to an Insecure Computer (not shown). 

Providers allow for essentially arbitrary scaling to large numbers of Users and 
for physical and logical partitioning of distribution of data to multiple Users. 
In one preferred embodiment, the network structure may comprise three levels: 
a repository acting as a Secure Processor to several providers, with each 
provider itself acting as a Secure Processor to several Users. It will be 
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d) As shown in figure 7, SP2 is the Secure Processor in the Repository and 
SP 1 is the Secure Processor in the Provider; 

In case (a) and (b), the protocol is the same as Secure Transfer Protocol (1), 
(1.8), or Secure Transfer Protocol (2), (1.9), except that during Step (6.), the 
now Guardian retrieves the Data based on the RequestedName. 

Typically cases (c) and (d) are used together (figure 7). 

In case (c), (figure 7) the protocol is the same as Secure Transfer Protocol (1), 
or (2), but during Step (6.) the Transferer 

either: 

cl) initiates an exchange of type (d) to retrieve the Data or Encrypted Data 
based on the RequestedName from the User 

or; 

c2) retrieves Data or Encrypted Data that originated from a previous 
exchange of type (d), from a store under its control. 

In the case of Encrypted Data, the Transferer may or may not choose to decrypt 
it. 

3. Third Scenario 

In this section we define a framework that extends the second scenario to 
support Policies that execute in Secure Processors, which automate the 
enforcement of rules on the processing and distribution. 
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The Policy could also describe how to determine the current version of the 
Data in a DataSet, or what to do when Data in a DataSet becomes out of date. 

The Policy could also contain rules about the key lengths, algorithms and its 
access control lists, and other data, which are used as a template when creating 
a Key Instance; and similarly on Program Data and Other Data. 

A Policy is typically signed by the object that is responsible for it, to ensure its 
authenticity and integrity. If so, a Policy is used only when this signature has 
been verified. 

The Policy could be transferred as Other Data with the Secure Transfer 
Protocol, or some other means, to execute or be interpreted on another Secure 
Processor. 

3.2 Region 

We turn now to figure 9. A Guardian 90 partitions the objects for which it is 
responsible into one or more domains, called f Region'(s) 91, such that each 
object exists in only one Region. 

A Region 91 contains: 

- one or more Entity(ies) 92 (each a secure processor) that can make requests of 
the associated Repository or Provider; 

- zero or more Policies 93, which define the rules that a DataSet and or objects 
in the Region must obey; 
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A Relying Party can then authenticate a message that the Entity called Entity 
Name, which they have signed with Kei-private, using Kei-public from the 
Entity Name's Certificate, obtained from the Guardian. 

5 For example, the binding of an Entity name to a kei-public is useful when 
defining policies, for instance it allows a security officer to specify by name 
which entities are allowed to use which application keys; or for linking an 
Entity's request for Data with a policy that, for example, charges that Entity 
Name's credit card; or securely records the transaction in an audit log, or to 

10 authenticate some other process. 

3.4 Secure Transfer Protocol (4) 

We turn now to figure 10. This instance of the protocol is the same as in 
1 5 Secure Transfer Protocol (3), (2.2), with these differences:- 

a) During Step (4.), the Guardian or the Transferrer confirms that the 
Entity associated with Kei-public is still a member of the Region and that its 
Kei-public is still available from the Guardian. 
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If so, it continues with the protocol; if not, it exists to Step (9.) with an error. 

b) During Step (6.), the Guardian or Transferer retrieves the Data as 
follows :- 

6. 1 ) Find the DataSet, T>S 1 that corresponds to the RequestedName. 



6.2) Find the Policy in DS1, Tolicyl' that corresponds to selecting 
Instance from the DataSet using RequestedName. 
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Before the Guardian retrieves the DataSet corresponding to RN1, it does the 
following:- 

1 . Retrieve all Authority Groups that contain EN1 ; 

2. Retrieve from these the Authority Group, AG1, that gives EN1 the right 
to download the DataSet associated with RN1 . 

3. Confirm that ENl's rights apply in the current context, for example, by 
running some associated Policy. 

4. Only if all these steps are successful, does the Guardian retrieve the Data 
associated with RN1 and send it to SP1. 

4.2 Region Authority Group 

The concept of the Region Authority Group is illustrated in figure 12. The 
Region Authority Group 121 is an administrative group which may be solely 
responsible for creating and deleting the Region's DataSets; and for 
maintaining the Policies associated with a DataSet. 

In the case when these Policies are signed, they are typically signed by the 
Region Authority Group, using 'Kgi-private'. 

The Regional Authority Group 121 may be responsible for enrolling an Entity 
into the Region, for authorizing a new Authority Group, or adding an Entity to 
an Authority Group. 
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In practice, the Guardian obtains the entities public key via some sort of private 
secure route. For example, where the entity is an office telephone, it may be 
enrolled to the Guardian in a secure room within the IT department. 
Alternatively, the information needed to be passed between the Guardian and 
the entity to effect enrolment may be done in some other secured way, 
including for example via physical documentation being passed through a 
company's internal mail system. 

4.4 Group Confidentiality 

One particular aspect of an Authority Group is that it could keep its Data and/or 
Policies private from Entities in other Authority Groups and, in particular, from 
the Repository and Provider. 

We call Data that is protected in this way Group Encrypted Data. 
To this end, an Authority Group 141 has: 

a) a Group Confidentiality Key symmetric key 142 ('Kgc-secret' for short) 
or; 

b) a Group Confidentiality Key Pair asymmetric key pair ('Kgc-private', Kgc- 
public'). 

c) The Repository receives Group Encrypted Data 143, which is placed there 
by an out-of-band process. 

Group Encrypted Data is encrypted using 
either: 
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Claims 



A method for the secure transmission of data from a distributor to a 
client over a computer network, the method comprising: 

(a) encrypting the data using an encryption confidentiality key 
known to the client but not the distributor; 

(b) storing the encrypted data at the distributor; 

(c) generating a message by further encrypting the encrypted data 
using an encryption transmission key, the corresponding 
transmission decryption key being known to the client; and 

(d) transmitting the message to the client. 

A method as claimed in claim 1 in which, on receipt of the message, the 
client confirms the authenticity of origin of the transmission by 
decrypting the message using the transmission key. 

A method as claimed in claim 2 in which the client confirms the 
confidentiality of the data by decrypting the encrypted data using a 
confidentiality decryption key corresponding to the confidentiality 
encryption key. 

A method as claimed in any one of claims 1 to 3 in which the data 
comprises or includes a cryptographic key. 

A method as claimed in any one of claims 1 to 3 in which the data 
comprises or includes a program. 

A method as claimed in any one of claims 1 to 3 in which the data 
comprises or includes licence or configuration information. 
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14. A method as claimed in claim 9 in which encrypted data held within the 
repository is divided into data sets, each data set being associated with a 
respective policy which defines how the data within the data set may be 
used. 

5 

15. A method as claimed in claim 14 in which data from a particular data 
set, when sent by the provider, is accompanied by the respective policy. 

16. A method as claimed in claim 15 in which the policy is run by the 
10 provider. 

17. A method as claimed in claim 14 or 15 in which the policy is run by the 
client. 



15 18. A method as claimed in claim 14 in which the policy is run by the 
repository 

19. A method as claimed in claim 9 in which a plurality of regions are 
defined within the repository, each region containing information on the 

20 secure computers that are permitted to make requests for or otherwise 

manipulate data held by the repository. 

20. A method as claimed in claim 9 in which the said secure computers 
include that of the provider. 

25 



21. 



A method as claimed in claim 9 in which the said secure computers 
include those of the clients. 
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30. A method as claimed in claim 19 in which the information within each 
authority group, when there is more than one such group, is encrypted 
and is confidential from other groups. 

31. A computer security module having means for receiving from a sender a 
message comprising twice-encrypted data, means for decrypting the 
message according to a protocol known to both the module and the 
sender, and means for further decrypting the decrypted message using a 
secret known to the module but not to the sender. 

32. A computer system including a plurality of clients, each having a 
security module as claimed in claim 31, and a provider arranged to send 
messages, as required, to the said clients. 

15 33. A computer system as claimed in claim 32 in which the provider 
includes a secure computer. 

34. A computer system as claimed in claim 33 in which the secure computer 
within the provider includes a security module as claimed in claim 31. 

20 

35. A computer system as claimed in any one of claims 32 to 34 including a 
plurality of providers, and a repository arranged to send data, as 
required, to the said providers. 

25 36. A computer system as claimed in claim 32 in which encrypted data is 
stored at the provider, and is re-encrypted prior to being sent as a 
message to the client. 
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A computer system as claimed in claim 35 in which a plurality of 
regions are defined with the repository, each region containing 
information on the secure computers that are permitted to make requests 
for or otherwise manipulate data held by the repository. 

A computer system as claimed in claim 45 when dependent upon claim 
33 in which the said secure computers include that of the provider. 

A computer system as claimed in claim 45 when dependent on claim 2 
in which the said secure computers include those of the clients. 

A computer system as claimed in claim 45 when dependent upon claim 
40 in which each region further includes a plurality of data sets. 

A computer system as claimed in claim 45 in which each region is 
associated with a respective region policy which defines how the 
information within the region may be used. 

A computer system as claimed in claim 45 in which each region further 
contains one or more authority groups, the or each group defining a set 
of secure computers that are permitted to carry out certain tasks. 

A computer system as claimed in claim 50 in which a given secure 
computer may belong to a plurality of authority groups. 

A computer system as claimed in claim 50 in which each region 
includes a region authority group which is responsible for administrative 
functions relating to its respective region. 
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(ii) recovering the data by decrypting the encrypted data using 
the secret. 

A method as claimed in claim 57 in which the data comprises or 
includes a cryptographic key. 

A method as claimed in claim 58 in which key management functions, 
for example key generation, are provided for the client by a secure 
external key management provider. 

A method as claimed in claim 58 in which the client is adapted to use 
cryptographic keys but not to generate them, instead requesting a key as 
required from a secure external key management provider. 

A method as claimed in claim 58 in which the key is used in a secure 
process by the client. 

A method as claimed in claim 57 in which the data comprises or 
includes a program. 

A method as claimed in claim 57 in which the data comprises or 
includes licence or configuration information. 

A method as claimed in any one of claims 57 to 63 in which the secret 
known to the client is not known to the distributor. 

A method as claimed in claim 64 in which the distributor generates the 
message by calculating 

encrypt(wrap({Ke-decrypt}, Kw-wrap), Ks) 
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A method as claimed in claim 64 in which the message generation 
includes wrapping the encrypted data with a symmetric entity 
confidentiality key which has been securely transferred in advance to the 
distributor. 

A method as claimed in claim 64 in which the message generation 
includes wrapping the encrypted data with the public part of an 
asymmetric entity confidentiality key pair, the said public part having 
been securely transferred in advance to the distributor. 

A method as claimed in claim 69 in which the distributor holds the said 
public part of the key pair confidential. 

A method as claimed in any one of claims 1 to 30 in which the client 
first sends the encryption confidentiality key to the distributor, which 
uses it to check whether the client is a valid client; the distributor being 
arranged to send the message only if the client is a valid client. 

A computer program for carrying out a method as claimed in any one of 
claims 1 to 30, or as claimed in any one of claims 57 to 72. 

A machine-readable data-carrier carrying a computer program as 
claimed in claim 73. 

A electronic data-stream representative of a computer program as 
claimed in claim 74. 
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1 Retrieve all Authority Groups that contain Entity 1 (El). 

2. Retrieve the Auth Group that gives El the right to 
retrieve DS1 and the associated Policy 1. 

3. Confirm ENl's rights, by securely running Policy 1. 

4. On success, return Data from DS1 . 
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